Skip to content

Replace PaginatedMessages with HistoryPage#25

Merged
zknill merged 1 commit intomainfrom
zak/paginated-history
Apr 14, 2026
Merged

Replace PaginatedMessages with HistoryPage#25
zknill merged 1 commit intomainfrom
zak/paginated-history

Conversation

@zknill
Copy link
Copy Markdown
Contributor

@zknill zknill commented Apr 2, 2026

The PaginatedMessages interface used parallel arrays (items, itemHeaders, itemSerials, rawMessages) matched by index — fragile and wider than its sole internal consumer (View) needs. Since the type is no longer part of the public API, consolidate into HistoryItem (message + headers + serial per item) and HistoryPage.

Also guard View.loadOlder() against concurrent calls — a second call while the first is still awaiting now silently no-ops instead of corrupting shared pagination state.

AIT-670, AIT-671

@zknill zknill requested a review from owenpearson April 2, 2026 11:08
@zknill zknill force-pushed the zak/paginated-history branch from 7cdaaa5 to ff9a4bc Compare April 10, 2026 09:33
Copy link
Copy Markdown
Member

@owenpearson owenpearson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good, one question:

@@ -197,8 +197,8 @@ export class DefaultView<TEvent, TMessage> implements View<TEvent, TMessage> {

async loadOlder(limit = 100): Promise<void> {
if (this._closed || this._loadingOlder) return;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be outside of the scope of this PR, but this looks weird to me: if you call loadOlder twice the second promise returned will resolve immediately even though the first promise is still busy loading older messages. Would it be better to reject the promise in this case?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not really an error though so I don't think reject is a good idea, it's just to stop concurrent calls to loadOlder. When the first one resolves the data will be available.

IMO it's not really a problem, but if we think it is, then I'd say we return a promise that resolves when the inflight call to loadOlder resolves.

@zknill zknill requested review from a team and mschristensen and removed request for a team April 13, 2026 08:57
@zknill zknill enabled auto-merge (rebase) April 14, 2026 08:32
The PaginatedMessages interface used parallel arrays (items,
itemHeaders, itemSerials, rawMessages) matched by index — fragile
and wider than its sole internal consumer (View) needs. Since the
type is no longer part of the public API, consolidate into
HistoryItem (message + headers + serial per item) and HistoryPage.

Also guard View.loadOlder() against concurrent calls — a second
call while the first is still awaiting now silently no-ops instead
of corrupting shared pagination state.

AIT-670, AIT-671
@github-actions
Copy link
Copy Markdown

Coverage Report

Status Category Percentage Covered / Total
🔵 Lines 92.7% 1982 / 2138
🔵 Statements 90.92% 2123 / 2335
🔵 Functions 93.26% 360 / 386
🔵 Branches 77.98% 889 / 1140
File Coverage
File Stmts Branches Functions Lines Uncovered Lines
Changed Files
src/core/transport/decode-history.ts 53.84% 30.64% 75% 55.85% 107-120, 124-147, 159-160, 171, 187, 192-206, 236-245, 281-288
src/core/transport/types.ts 0% 0% 0% 0%
src/core/transport/view.ts 85.98% 72.99% 98% 89.25% 218, 222-223, 230-231, 236-237, 255, 270, 331, 403, 415-418, 434-442, 491, 494, 497, 520, 531, 542, 571-574, 703-714
Generated in workflow #49 for commit c27491b by the Vitest Coverage Report Action

@zknill zknill merged commit eed5e51 into main Apr 14, 2026
13 checks passed
@zknill zknill deleted the zak/paginated-history branch April 14, 2026 08:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants